BRIEF DESCRIPTION OF THE DRAWINGS 



The above and other objects, features and advantages of the present invention will 
become more apparent from the following detailed description when taken in conjunction with 
the accompanying drawings in which: 

FIG. 1 illustrates the configuration of a typical WLAN as an example of a wireless 
network; 

FIG. 2 illustrates a hierarchy of proactive securitv keys in the typical WLAN; 
FIG. 3 illustrates an example of key assignment to each component in the typical WLAN; 
FIG. 4 illustrates assignment of a pfeaettv esecurity key needed for roaming in a 
conventional WLAN; 

FIGs. 5 A and 5B illustrate AP-neighborhood graph generation according to the present 
invention; 

FIG. 6 illustrates an example of a roaming path in which an STA roams, referred to for 
describing the present invention; 

FIG. 7 illustrates generation of proactive securitv keys according to an embodiment of the 
present invention; 

FIGs. 8A, 8B and 8C illustrate a roaming process according to the embodiment of the 
present invention; 

FIG. 9 is a diagram illustrating signaling in the roaming process according to the 
embodiment of the present invention; 

FIGs. 10A to 10E illustrate a roaming process according to another embodiment of the 
present invention; 

FIG. 1 1 illustrates an example of PMKs generated for a particular STA roam pattern; 

FIG. 12 is a diagram illustrating signaling for initial association in the typical WLAN; 

FIG. 13 is a diagram illustrating signaling before roaming according to the second 
embodiment of the present invention; 

FIG. 14 is a diagram illustrating signaling after roaming according to the second 
embodiment of the present invention; and 



FIG. 15 is a graph comparing experiment results for a conventional roaming scheme (full 
authentication) and a roaming scheme of the present invention (re-authentications). 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Preferred embodiments of the present invention will be described herein below with 
reference to the accompanying drawings. In the following description, well-known functions or 
constructions are not described in detail since they would obscure the invention in unnecessary 
detail. 

Three schemes can be considered to support fast roaming in a WLAN. 

First, APs each preserve all necessary proactiv e security keys for roaming. Each AP 
reserves memory space for the roaming service, stores all pfeaetwe securitv keys needed for the 
roaming service in the memory, and retrieves one proactive security key from the memory when 
necessary. A distinctive shortcoming of this scheme is the requirement of a large-capacity 
memory. 

A second scheme is to provide neighbor APs with necessary proactive security keys for 
roaming by proactiv e security caching accomplished by the LAPP protocol. To do so, each AP 
manages information about its neighbor APs using an AP-neighborhood graph. Also, the AP 
generates proactiv e security keys for the neighbor APs using a known proactiv e security key and 
provides the generated proactive security keys to the neighbor APs by the proactiv e security 
caching. 

The third scheme is that a higher-layer server (accounting server) manages neighbor APs 
for each AP and provides the neighbor APs with proactiv e security keys necessary for roaming 
when an STA accesses the AP. To implement this scheme, the higher-layer server is provided to 
manage the AP-neighborhood graph for each AP. The higher-layer server may be an existing 
AAA server or a separately procured server. Depending on the amount of information regarding 
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the managed AP-neighborhood graphs, a plurality of higher-layer servers can be used. 

The above-described second and third schemes are implemented as first and second 
embodiments of the present invention. These embodiments commonly require the AP- 
neighborhood graph by which neighbor APs are managed for each AP. They differ in that each 
AP manages its AP-neighborhood graph in the first embodiment, while a higher-layer server 
manages its AP-neighborhood graph in the second embodiment. In the embodiments of the 
present invention, the process of providing potential APs with proactive security keys needed for 
roaming is further included. The AP-neighborhood graph is required in both embodiments since 
the potential APs are a set of APs to which an ST A may move. The AP-neighborhood graph 
defines connections between an STA and its potential APs, which the STA may be associated 
with by roaming. Hence, before detailing the embodiments of the present invention, the process 
of how the AP-neighborhood graph is created will first be described. 

1 . Generation of AP-Neighborhood Graph 

The AP-neighborhood graph required to implement the present invention can be 
generated based on the locations of APs in a WLAN. Because potential APs are different for 
each AP, an AP-neighborhood graph is created for each AP. This is done in three methods. One 
of them is that an administrator manually generates AP-neighborhood graphs for individual APs 
based on the locations of the APs and registers them. Each time a change is made to the AP 
layout, the administrator updates the AP-neighborhood graphs. Another method is that initial AP- 
neighborhood graphs are registered by the administrator and automatically updated each time the 
AP layout is changed. 

The third method is that the AP-neighborhood graph is automatically generated for each 
AP and automatically updated each time the AP layout is changed. According to this method, 
however, roaming is carried out by the conventional roaming process until the AP-neighborhood 
graph is generated. In other words, a procedure for checking connections to each AP is needed. 
For example, if an STA associated to AP_A attempts to initially roam to APJB that the STA has 
never moved to, AP_B performs an LAPP procedure to receive a context corresponding to the 
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STA from AP_A. AP_A and AP_B then confirm that there is a connection between them for 
roaming and thus can update their AP-neighborhood graphs. After the updating, the STA can 
roam from AP_A to AP_B or vice versa without the LAPP procedure. 

The physical path and distance between APs are considerations to take into account when 
constructing an AP-neighborhood graph in any of the above methods. To draw a connection 
between APs in an AP-neighborhood graph, there must exist a physical connection between the 
APs without passing through any other AP. Also, the distance between the physically connected 
APs should not exceed a threshold. As a matter of fact, the STA would perform an initial 
procedure for establishing a communication with a nearby AP rather than roam to a remote AP. 

An example of an AP-neighborhood graph will be shown below. 

FIG. 5 A illustrates an example of an AP layout in a WLAN to which the present 
invention is applied and FIG. 5B illustrates an AP-neighborhood graph constructed based on the 
AP layout. 

Referring to FIG. 5A, AP_C is located in a closed space with one entrance. Thus AP_B is 
the only AP to which an STA can move from AP_C. This implies that roaming only to AP_B is 
allowed for the STA in AP_C. Meanwhile, an STA in AP_B can move to any of AP_A, AP_D, 
AP_E and AP_C because corridors (physical connections) run from AP_B to these APs. That is, 
the STA is free to roam from AP_B to all APs illustrated in FIG. 5 A. If the STA is located in 
AP_A, it can only move to APJB or AP_E without passing through any other AP. Hence, the 
STA can roam from AP_A to APB or AP_E. APJE is directly connected to all APs except 
AP_C, so that an STA in APJE can roam to any of the APs other than APC. Direct roaming for 
an STA from APJD is confined to AP B and AP_E. Roaming from AP A to APJD, or from 
AP_D to AP_A, is not allowed due to a long distance between them. Instead of roaming, the 
STA reassociates to AP_B before it roams to AP_D or AP_A. 

Referring to FIG. 5B, the illustrated AP-neighborhood graph shows all of the connections 
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among the APs in the WLAN. Yet, the above-described second neighborhood graph generation 
method is viable as long as each AP has knowledge of potential APs to which it may have 
connectivity. For example, knowledge of AP_B and AP__E as potential APs is substantially 
sufficient for AP_A and knowledge of AP_A, AP_C, APD and APJ3 as potential APs is 
substantially sufficient for AP_B. On the other hand, in the third neighborhood graph generation 
method, an accounting server manages an AP-neighborhood graph for each AP. 

As mentioned earlier, the AP-neighborhood graph is manually generated by the 
administrator or automatically generated by the conventional handoff procedure. 

In the case where each AP automatically generates an AP-neighborhood graph, upon 
receipt of a reassignment request message from an STA, the AP determines whether a 
temporarily stored context corresponding to the STA exists. The AP is a new-AP for the STA. If 
the context exists, it means that the AP has already created an AP-neighborhood graph containing 
a prior- AP to which the STA had connectivity. On the contrary, if the context is absent, it means 
that connectivity to the prior- AP has not yet been defined in the AP-neighborhood graph. The 
new-AP then receives the context corresponding to the STA from the prior- AP by the 
conventional LAPP procedure and updates the AP-neighborhood graph so that a connection line 
is drawn between the new-AP and the prior- AP in the AP-neighborhood graph. 

In this manner, the AP-neighborhood graph is generated in the first embodiment of the 
present invention characterized by management of the AP-neighborhood graph at each AP. 
Meanwhile, in the second embodiment of the present invention, since a higher-layer server 
manages an AP-neighborhood graph for each AP, when a new connection is established, a 
corresponding AP reports the new connection to the higher-layer server so that the AP- 
neighborhood graph of the AP can be updated with the latest information. It is also possible that 
if an STA roams to a new-AP, the higher-layer server updates an AP-neighborhood graph for a 
prior- AP by adding the new-AP to the graph as a neighbor AP of the prior- AP. 

2. First Embodiment 
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An AP generates PMKs for neighbor APs managed in its AP-neighborhood graph and 
transmits the PMKs to the neighbor APs using a proactiv e securitv caching technique 
accomplished by the LAPP protocol. When an STA roams to one of the neighbor APs, a security 
system operates based on the PMK provided to the neighbor AP, thereby enabling fast roaming. 

The proactive securitv caching technique refers to a scheme in which each AP recognizes 
potential APs that it may get connectivity to by its AP-neighborhood graph, generates PMKs for 
the potential APs, and transmits the PMKs to the neighbor APs. Therefore, re-authentication 
latency involved in the roaming process is minimized. The proactive securitv caching technique is 
based on a locality of mobility principle. In this environment, an STA association pattern is the 
sequence of APs that the STA becomes associated with in a given interval of time. 

The first embodiment of the present invention will be detailed with reference to the 
attached drawings. It is assumed herein that each AP manages its own AP-neighborhood graph. 

FIG. 6 is a view conceptually illustrating a roaming process by the proacti ve securitv 
caching technique according to the present invention. The roaming process presupposes that an 
STA moves from AP_A to AP_B. 

Referring to FIG. 6, the STA transmits an association request to AP_A in step 1. AP_A 
authenticates the STA in a general initial authentication procedure and acquires a 
proactive securitv key. The STA already knows an MK used for security between the STA and an 
AAA server (not shown) and receives a PMK from the AAA server. AP_A receives the PMK 
from the AAA server. Both the STA and the AP_A then acquire a PTK and an RK (Roam Key). 
A random number (RN) is needed to generate the RK and a 4-way handshake is carried out using 
the PMK to generate the PTK. The RN is generated during the 4-way handshake. Obviously, the 
RN may be generated in any other way. After the authentication, AP__A transmits a response for 
the association request to the STA. Thus, the STA communicates with AP_A. 

Meanwhile, AP_A generates a PMK for a neighbor AP, AP_B, managed by its AP- 
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neighborhood graph. Let the PMK for the neighbor AP be PMK next . PMKn ex t is generated using 
the RK, the current PMK, PMKc Urr , the MAC address of the STA, STA mac , and the MAC address 
of a new- AP, next AP mac by a PRF (Pseudo-Random Function), expressed as 

PMKnext = PRF(RK, PMKc UIT , STA mac , next AP mac ) 

(1) 

where STA mac is known to AP_A during communication and next AP mac is information that 
AP_A receives by the IAPP protocol or from the AAA server. 

In step 2, AP_A transmits PMK nex t to AP_B. While one AP is assumed as a potential AP 
in the case illustrated in FIG. 6, if a plurality of potential APs exist, AP_A transmits PMKs, 
PMKn ex t calculated for the respective potential APs to each of them. AP_B stores PMK nex t in a 
cache. As the STA moves to AP_B in the shown path, the STA requests a reassociation to AP_B 
in step 3. To maintain an on-going communication service in response to the reassociation 
request, a security system must be established between AP_B and the STA. That is, a PTK must 
be gained for security between AP_B and the STA. The PTK is derived from a PMK, namely 
PMKnext. Hence, APB sets PMK next as the PMK by which AP_B can communicate with the 
STA. Meanwhile, the STA can gain PMK nex t in various ways. For example, AP_A or AP_B 
provides the STA with PMK nex t. Or the STA can directly generate PMK next from next AP mac 
received from AP_A or AP_B. 

As AP_B and the STA acquire the same PMK, the PTK can be created in the 
conventional method, so that a normal security system can be established between them. 
Consequently, the latency involved with the conventional pre-authentication is reduced, thereby 
enabling fast roaming and achieving implementation speedups. In the mean time, AP_B 
generates PMK next using an RK achieved together with the PTK and transmits PMK next to its 
neighbor APs, in preparation for roaming of the STA to any of the neighbor APs. 

In the embodiment of the present invention, the proactiv e security caching technique is 
adopted to provide a preae&v esecurity key used to preserve security between an STA and at least 
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one predicted new-AP to which the STA becomes associated. Apart from the roaming process, 
the proactive security caching involves the transfer of the proactive securitv key from a prior- AP 
to potential new-APs. To implement the proactiv e securitv caching technique, potential new-APs 
for each AP must be predicted. This has been detailed in relation to the AP-neighborhood graph. 

FIG. 7 illustrates a proactive securitv key generation procedure according to the first 
embodiment of the present invention. 

Referring to FIG. 7, the AAA server generates PMKc Urr for an AP, AP curr that the STA 
initially attempts to access and transmits PMKcurr to AP cur r. AP cur r acquires a PTK and an RK 
from PMKcurr. The RK is determined using a PRF expressed as 

RK - PRF(PMK, "Roam Key", AP n0 nce, STA non ce) 

(2) 

where AP n0 nce is a random number set by AP CU rr, STA noriC e is a random number set by the STA, 
and "Roam Key" is the RN generated during the 4-way handshake. 

After the RK is gained by Eq. (2), a PMK for a neighbor AP, PMK nex t is computed by Eq. 
(1) and transmitted to AP nex t by the proactiv e securitv caching technique. In the presence of a 
plurality of neighbor APs, as many PMKs, PMK nex t as the number of the neighbor APs are 
generated. 

The provisioning of the fast roaming service with a reduced reassociation latency owing 
to the proactive securitv caching technique will be described in detail with reference to FIGs. 8A, 
8B and 8C. It is to be appreciated that the following description is under the assumption that the 
STA is initially connected to AP_A, and AP_B and AP_E are neighbor APs to AP_A. 

FIG. 8 A illustrates acquisition of necessary proactive securitv keys in AP_A and the STA 
when the STA initially attempts to access AP_A. The proactive securitv keys the STA acquires 
are MK, PMKc Urr , PTKc ur r and RK, while the p roactiv e securitv keys AP_A acquires are PMKcurr, 
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PTKcurr and RK. The procedure for acquiring the p r o a c t i ve security keys has been described 
earlier and thus its description is not provided here. 

FIG. 8B illustrates the generation of PMKs for neighbor APs using the proactiv e security 
keys in AP_A and the transfer of them from AP_A to the neighbor APs by the preae&v esecurity 
caching technique. In this example the neighbor APs to AP_A are AP_B and AP_E. PMK nex t for 
APJB (PMK(AP_B)next) is determined by 

PMK(AP_B) next = PRF(RK, PMKc Urr , STA mac , AP_B mac ) 

(3) 

and PMKnext for AP_E (PMK(AP_E) nex t) is determined by 

PMK(AP_E)next = PRF(RK, PMKc urT , STA mac , AP_E mac ) 

(4) 

For roaming that may occur later, the ST A must have knowledge of PMK nex t 
corresponding to the neighbor APs. In accordance with the first embodiment of the present 
invention, the STA gains PMK nex t corresponding to the neighbor APs in two ways, AP_A 
directly provides the STA with PMK nex t delivered to the neighbor APs; and AP_A provides the 
STA with MAC addresses needed to calculate PMK nex t for the neighbor APs. In the latter case, 
the STA computes PMK nex t for the respective neighbor APs by Eq. (3) and Eq. (4). 

FIG. 8C illustrates AP_B's resumption of a communication service that AP_A provided, 
using PMKnext after the STA moves from AP_A to AP_B. AP_B translates PMK next received 
from AP_A into its PMK. If the STA attempts to access AP_B, AP_B derives a PTK from the 
PMK. Similarly, the STA acquires the PTK using already known PMK next . Thus, the STA 
resumes the communication service with AP_B, which was provided in AP_A. Meanwhile, 
AP_B acquires the PTK and an RK simultaneously. Using the RK, AP_B generates PMKs for its 
neighbor APs managed by its AP-neighborhood graph. AP_B transmits the PMKs to the 
neighbor APs by the pr o activ e security caching technique. 
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Although the case illustrated in FIGs. 8A, 8B and 8C has been detailed on the assumption 
that the STA roams from AP_A to AP_B, the STA can roam from APB to AP_A in the same 
procedure. 

FIG. 9 is a diagram illustrating signaling between the STA and the APs in the roaming 
process according to the first embodiment of the present invention. Let AP_A be a prior- AP and 
AP_B be a new-AP. Since the STA accesses AP_A and after roaming, the STA operates with 
APB in the conventional manner, the following description is focused on the signaling for the 
roaming process. 

Referring to FIG. 9, the STA and AP_A derive a PTK and an RK from a PMK received 
from the AAA server (not shown) in step 901 so that they are capable of communicating with 
each other. APA derives PMKs, PMK nex t for its neighbor APs in step 903 and transmits the 
PMKs to its neighbor APs in steps 905 to 907. Thus the neighbor Aps now have the PMKs which 
will be used for security when the STA moves to them. 

As the STA roams to AP_B, the STA and AP_B derive a PTK and an RK from PMK nex t 
in step 909, so that STA and AP_B establish a security system that allows a communication 
service from AP_A to be resumed in APB. AP_B generates PMKs, PMK nex t for its neighbor 
APs in step 91 1 and transmits the PMKs to its neighbor APs in steps 913 to 915. 

In accordance with the first embodiment of the present invention, the need for accessing 
the AAA server for pre-authentication needed to provide a roaming service for the STA is 
eliminated, thereby reducing time required for roaming. This implies that fast roaming is enabled. 

3. Second Embodiment 

Higher-layer servers manage neighbor APs for individual APs by their AP-neighborhood 
graphs. When necessary, the servers generate PMKs for APs neighboring to a particular AP and 
transmits them to the neighbor APs. Thus when an STA roams to one of the neighbor APs, a 
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security system operates using the already known PMK, thereby providing fast roaming. 

The second embodiment of the present invention presupposes that the AP-neighborhood 
graphs are managed by a novel higher-layer server, an accounting server. The accounting server 
may be incorporated in an existing AAA server or implemented as a separate server. Also, a 
plurality of accounting servers can be adopted according to the amount of information regarding 
the managed AP-neighborhood graphs. It is to be appreciated that the following description is 
made in the context of an accounting server implemented independently of an existing AAA 
server and this AAA server free of the accounting function is called an authentication server 
(AS). 

With reference to FIGs. 10A to 10E, fast roaming through proactive securitv key 
distribution from the higher-layer servers will be described in detail on the assumption that the 
STA initially accesses AP_A, and AP_B and AP_E are neighboring to AP_A. 

Referring to FIG. 10A, as the STA initially attempts to associate to AP_A, AP_A and the 
STA each acquire their necessary proactiv e securitv keys. An MK, a PMK and a PTK are 
proactiv e securitv keys for the STA, while the PMK and the PTK are proactiv e securitv keys for 
AP_A. How the keys are acquired has been detailed earlier and thus its description is not 
provided here. The acquisition of the proactiv esecuritv keys is equivalent to establishment of a 
security system that allows communication between the STA and AP_A. 

Referring to FIG. 10B, AP_A notifies the accounting server of the initiation of a 
communication service with the STA, for example by an Accounting-Request message. Thus the 
accounting server executes an accounting function for the STA and announces the initiation of 
the communication service between the STA and AP_A to the neighbor APs. 

Referring to FIG. IOC, the accounting server searches for the neighbor APs using an AP- 
neighborhood graph that the accounting server manages for AP_A, and notifies by a Notify- 
Request message the neighbor APs, AP_B and AP_E, that the STA has associated to AP_A. The 
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Notify-Request message includes the MAC address of the STA, STA-mac-Addr. Upon receipt of 
the Notify-Request message, APB and AP E consider that the STA is likely to move from 
AP_A to them. 

Referring to FIG. 10D, the AS provides the neighbor APs (AP_B shown as a 
representative) with PMKs by which they can communication with the STA if and when it roams 
to them. Specifically, AP_B transmits to the AS an Access-Request message including STA- 
mac-Addr received from the accounting server, and the AS generates a PMK, PMK B for AP_B 
by 

PMK B = PRF(MK, PMK A , STA mac , AP_B mac ) 

(5) 

where PMK A is a PMK assigned to AP_A, and STA,™ and AP_B mac are the respective MAC 
addresses of the STA and AP_B . 

The AS transmits to AP B an Access-Accept message including PMK B . By receiving the 
Access- Accept message, AP_B acquires the PMK to use for security between the STA and AP B 
when the STA moves to AP B. While FIG. 10D illustrates an operation between AP B and the 
AS, the same thing is also applicable to AP_E. 

Referring to FIG. 10E, a roaming service is provided to the STA as the STA moves to 
AP_B. When the STA attempts to access AP_B, AP_B reports the access attempt to the 
accounting server. The accounting server then updates an AP-neighborhood graph for AP_B. 
Meanwhile, the STA acquires the PMK, PMK B required to establish a security system with 
AP_Bby 

PMK B = PRF(MK, PMK A , STA™, AP_B mac ) 

(6) 

where PMK A is a PMK assigned to AP_A, and STA mac and AP_B mac are the MAC addresses of 
the STA and AP_B. The STA already has the knowledge of PMK A and STAmac, while it cannot 
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know AP_B mac without aid from an external device. Therefore, the STA receives AP_B mac from 
AP_A, or from AP_B after it moves to AP_B. Alternatively, the STA may receive PMK B from 
AP_B, instead of generating PMK B directly. This is possible on the assumption that APJB has 
PMK B , which has been described earlier. 

Once AP_B and the STA know PMK B , they can acquire a PTK from PMK B in a known 
manner. Thus, the method of deriving the PTK from PMK B will not be described here. 

In the above-described procedure, the STA and AP_B share the same PTK. This implies 
that a security system has been established between the STA and AP_B. Therefore, a 
communication service provided from AP_A can be resumed between the AP_N and the STA. 

FIG. 1 1 illustrates an example of PMK generation when the STA roams in a pattern of 
AP_A, APB, and AP C or AP D in this order. 

Referring to FIG. 1 1, as the STA initially associates to AP_A, PMKo is generated in a 
first generation stage. In a second generation stage, the AS generates PMK B for AP_B from 
PMKo in preparation for roaming of the STA to AP_B. As the STA roams to AP_B, the AS 
generates PMKc for AP_C from PMK B in preparation for roaming of the STA to AP_C in a third 
generation stage. In a fourth generation stage, the AS generates PMK D for AP_D from PMK B and 
PMK B for AP_B from PMKc in preparation for roaming of the STA to AP_D or AP_B. In a fifth 
generation stage, the AS generates PMK B for AP_B and PMK E for AP_E from PMK D in 
preparation for roaming of the STA from AP_D to AP_B or AP_E. 

Sequential generation of a PMK for the next AP from a PMK for the previous PMK and 
generation of PMKS for next PMKs from the same previous PMK have been described. Only 
normal transfer of the PMKs from an AP to the neighbor APs has been considered in the above 
description. Nonetheless, erroneous PMK transfer causes no security problems because a 
neighbor AP can acquire a PMK in the conventional roaming process when it fails to acquire the 
PMK due to the erroneous PMK transfer. 
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FIG. 13 is a diagram illustrating signaling before the STA roams according to the second 
embodiment of the present invention. In FIG. 13, an AP that the STA initially associates with is 
called a first AP, and potential APs to which the STA may move are called first and second 
neighbor APs, respectively. 

Referring to FIG. 13, an initial association procedure is carried out among the STA, the 
first AP and the AS, as illustrated in FIG. 12 for acquisition of proactiv e securitv keys needed for 
the initial association. In step 1301 the first AP notifies the accounting server of the start of a 
communication service with the STA by an Accounting-Request message including Acct-Multi- 
Session-ID and PMK-Generation. Upon receipt of the Accounting-Request message, the 
accounting server determines whether an AP-neighborhood graph is managed for the first AP and 
transmits an Accounting-Response message to the first AP in step 1303. At the same time, the 
accounting server confirms that the first and second neighbor APs exist for the first AP by the 
AP-neighborhood graph. 

The accounting server transmits a Notify-Request message to the first neighbor AP in 
step 1305 and to the second neighbor AP in step 1307. The Notify-Request message indicates the 
association of the STA to the first AP. This message delivers information about Acct-Session-ED, 
Acct-Multi-Session-ID, and PMK-Generation. By receiving the Notify-Request message, the first 
and second neighbor APs consider that the STA may move from the first AP to them. The first 
neighbor AP transmits a Notify-Response Message to the accounting server in step 1309 and the 
second neighbor AP transmits another Notify-Response Message to the accounting server in step 
1311. 

The first and second neighbor APs transmit to the AS an Access-Request message 
including Acct-Session-ID, Acct-Multi-Session-K) and PMK-Generation in steps 1313 and 1317, 
respectively. 

Upon receipt of the Access-Request message from the first neighbor AP, the AS 
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generates a PMK for the first neighbor AP. In step 1315, the AS transmits to the first neighbor 
AP an Access-Accept message including the generated PMK. The Access-Accept message 
delivers information about Acct-Session-ID, Acct-Multi-Session-ID, PMK-Generation, PMK and 
Timeout. By receiving the Access- Accept message, the first neighbor AP acquires the PMK for a 
security system which allows secure communication with the STA after the STA moves to the 
first neighbor AP. 

Upon receipt of the Access-Request message from the second neighbor AP, the AS 
generates a PMK for the second neighbor AP and transmits to the second neighbor AP an 
Access-Accept message including the generated PMK in step 1319. The Access- Accept message 
delivers information about Acct-Session-ID, Acct-Multi-Session-ID, PMK-Generation, PMK and 
Timeout. By receiving the Access- Accept message, the second neighbor AP acquires the PMK 
for a security system which allows secure communication with the STA after the STA moves to 
the second neighbor AP. 

Meanwhile, the STA and the first AP perform typical operations needed for a 
communication service between them, such as acquisition of a PTK by 4-way handshake. When 
the communication service is available, the STA and the first AP transmit/receive 
communication service data. 

FIG. 14 is a diagram illustrating signaling after the STA roams according to the second 
embodiment of the present invention. In FIG. 14, the STA moves from the first AP to the first 
neighbor AP and the first AP and the second neighbor AP are neighbor APs to the first neighbor 
AP. 

Referring to FIG. 14, after the STA moves to the first neighbor AP, it attempts to 
reassociate to the first neighbor AP by transmitting a Probe Request message to the first neighbor 
AP in step 1401. In step 1403, the first neighbor AP transmits to the STA a Probe Response 
message in response to the Probe Request message. The STA transmits a Reassociation Request 
RSN IE to the first neighbor AP in step 1409 and the first neighbor AP transmits a Reassociation 



-25- 



Response RSN IE to the ST A in step 1411. 



Meanwhile, the first neighbor AP transmits an Accounting-Request message to the 
accounting server to report the reassociation of the ST A to the first neighbor AP in step 1413. 
The Accounting-Request message contains information about Acct-Multi- Session-ID and PMK- 
Generation. Upon receipt of the Accounting-Request message, the accounting server updates the 
AP-neighborhood graph corresponding to the first neighbor AP. The accounting server transmits 
an Accounting-Response message to the first neighbor AP in step 1415. At this time, the 
accounting server confirms by the AP-neighborhood graph that the first AP and the second 
neighbor AP are neighboring to the first neighbor AP. 

The accounting server transmits a Notify-Request message to the first AP in step 1417 
and to the second neighbor AP in step 1419. The Notify-Request message indicates the 
association of the STA to the first neighbor AP. This message delivers information about Acct- 
Session-H), Acct-Multi-Session-ID, and PMK-Generation. By receiving the Notify-Request 
message, the first AP and the second neighbor AP consider that the STA may move from the first 
neighbor AP to them. The first AP transmits a Notify-Response Message to the accounting server 
in step 1421 and the second neighbor AP transmits another Notify-Response Message to the 
accounting server in step 1423. 

Upon receipt of the Notify-Request message, the first AP transmits an Access-Request 
message to the AS in step 1425. The Access-Request message contains information about Acct- 
Session-ID, Acct-Multi-Session-ID, and PMK-Generation. 

Upon receipt of the Notify-Request message from the first AP, the AS generates a PMK 
for the first AP, for example, referring to the information included in the Access-Request 
message. The AS then transmits an Access-Accept message to the first AP in step 1427. The 
Access- Accept message contains information about Acct-Session-ID, Acct-Multi-Session-ID, 
PMK-Generation, PMK and Timeout. By receiving the Access-Accept message, the first AP 
acquires the PMK for a security system which allows secure communication with the STA after 
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the STA moves to the first AP. 

Upon receipt of the Notify-Request message, the second neighbor AP transmits an 
Access-Request message to the AS in step 1429. The Access-Request message contains 
information about Acct-Session-ID, Acct-Multi-Session-ID, and PMK-Generation. 

Upon receipt of the Notify-Request message from the second neighbor AP, the AS 
generates a PMK for the second neighbor AP, for example, referring to the information included 
in the Access-Request message. The AS then transmits an Access- Accept message to the second 
neighbor AP in step 1431. The Access- Accept message contains information about Acct-Session- 
ID, Acct-Multi-Session-ID, PMK-Generation, PMK and Timeout. By receiving the Access- 
Accept message, the second neighbor AP acquires the PMK for a security system which allows 
secure communication with the STA after the STA moves to the second neighbor AP. 

Meanwhile, the STA and the first neighbor AP perform typical operations needed for a 
communication service between them, such as acquisition of a PTK by 4-way handshake. When 
the communication service is available, the STA and the first neighbor AP transmit/receive 
communication service data. 

It can be further contemplated as other embodiments that the step of determining whether 
to apply the inventive roaming technique between an STA and APs is further performed in 
addition to the procedures according to the first and second embodiments of the present 
invention. For example, the STA notifies whether it supports fast roaming by one of reserved bits 
in the RSN IE of a Reassociation-Request message. The AP notifies whether it supports fast 
roaming by the same bit of a Reassociation-Response message. A PMK acquired for the STA can 
be provided by the bit. 

FIG. 15 is a graph illustrating the results of an experiment that compares the conventional 
roaming scheme (full authentication) with the inventive roaming scheme (re-authentications). As 
noted from FIG. 15, latency of about 800ms was observed in the full authentication, whereas the 
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latency was reduced to 50ms on an average in the re-authentications. Thus the conclusion is 
drawn that the inventive roaming scheme supports fast roaming. 

As described above, the present invention offers a simplified roaming process and so 
reduces roaming time, resulting in communication implementation speedup between an STA and 
a new-AP in a WLAN. Also, service quality is stably ensured and fast roaming is enabled. 

While the invention has been shown and described with reference to certain preferred 
embodiments thereof, it will be understood by those skilled in the art that various changes in 
form and details may be made therein without departing from the spirit and scope of the 
invention as defined by the appended claims. 
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REMARKS 

Claims 1-15 are pending in the application. It is gratefully acknowledged that Claims 4, 5, 
7, 8, 10, 1 1 and 15 have been objected to as being dependent upon a rejected base claim, but 
would be allowable if rewritten in independent form to include all of the limitations of the base 
claim and any intervening claims. The Examiner has rejected Claims 1-3, 6, 9 and 12-14 under 
35 U.S.C. § 102(e) as being anticipated by Lee et al. (U.S. Publication 2005/0117524). 

The specification, abstract and claims have been amended to replace "proactive" with 
"security" as set forth herein. The change clarifies the terminology used herein. No new matter 
has been added. A clean version of the specification is attached hereto as required. 

Regarding the rejection of Claims 1-3, 6, 9 and 12-14 under §102(e), the Examiner states 
that Lee et al. anticipates all of the elements of the claims. It is respectfully submitted that the 
inventive entity of the present application and Lee et al. are in fact the same. It is therefore 
respectfully submitted that since Lee et al. is the same inventive entity as the present application 
and not "by another", Lee et al. cannot be used as art under § 102(e). 

Based on at least the foregoing, withdrawal of the rejections of Claims 1-3, 6, 9 and 12-14 
under § 102(e) is respectfully requested. 

Independent Claims 1, 6, 9 and 12 are believed to be in condition for allowance. Without 
conceding the patentability per se of dependent Claims 2-5, 7, 8, 10, 1 1 and 13-15, these are 
likewise believed to be allowable by virtue of their dependence on their respective amended 
independent claims. Accordingly, reconsideration and withdrawal of the rejections of dependent 
Claims 2-5, 7, 8, 10, 11 and 13-15 is respectfully requested. 

Accordingly, all of the claims pending in the Application, namely, Claims 1-15, are 
believed to be in condition for allowance. Should the Examiner believe that a telephone 
conference or personal interview would facilitate resolution of any remaining matters, the 
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Examiner may contact Applicant's attorney at the number given below. 



DILWORTH & BARRESE 
333 Earle Ovington Blvd. 
Uniondale, New York 1 1553 
Tel: (516)228-8484 
Fax: (516)228-8516 

PJF/MJM/dr 



Respectfully submitted, 



Paul J. Karrell 
Reg. No. 33,494 
Attorney for Applicant 
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